platforms/blabsy/src/pages/404.tsx (1)

5-6: 404 page dark-mode hardcoding is consistent with app-wide theme

The isDarkMode = true constant and passing it to withDarkMode keep the 404 page aligned with the globally forced dark theme, and the description copy tweak is fine. If you want to trim a tiny bit of indirection later, you could inline the boolean directly into the Error props and drop the constant, but it’s not necessary.

Also applies to: 12-12

platforms/blabsy/src/components/modal/display-modal.tsx (1)

5-5: Modal changes correctly reflect removal of theme selection

Importing only Accent matches the remaining usage, and the comment about theme selection being removed clearly documents that dark mode is enforced elsewhere. You might later adjust the modal text (“Customize your view”) to hint that only color accents are configurable now, but the current implementation is coherent with the PR’s goal.

Also applies to: 73-73

platforms/blabsy/src/lib/context/theme-context.tsx (4)

25-26: Initial theme hardcoded to dark is straightforward and safe

Always returning 'dark' from setInitialTheme cleanly matches the “permanent dark mode” requirement and avoids any window/storage checks on initialization. No issues here; if dark mode is truly permanent, you could eventually inline this and drop the separate helper to reduce indirection.

---

47-49: Effect re-enforcing dark theme on user changes is defensive but not strictly needed

Resetting theme to 'dark' whenever userId or userTheme changes guarantees consumers never see anything else, but given the initial state is already 'dark' and runtime switching is disabled, this effect is largely redundant. It’s fine to keep for safety; consider removing it later if you want to simplify the context.

---

56-67: Flip-theme effect correctly forces dark mode; some redundant work you can trim

The flipTheme effect now consistently:

• Ensures the root element has the dark class.
• Sets the dark variants of the main background/search/sidebar CSS variables.
• Persists 'dark' to localStorage and updates the user theme via updateUserTheme.

That matches the PR objective and looks functionally sound. There are a couple of small cleanups you can make later to reduce redundancy:

• root.classList.add('dark') followed by a classList.contains check that can only ever be true in single-threaded JS is effectively redundant.
• The extra document.documentElement + root.classList.add('dark') after calling flipTheme() redoes what flipTheme already does.

A minimal refactor to remove that duplication could look like:

-        const flipTheme = (): NodeJS.Timeout | undefined => {
-            const root = document.documentElement;
-            // Always use dark theme
-            const forcedTheme: Theme = 'dark';
-            
-            // Always ensure dark class is present and never remove it
-            root.classList.add('dark');
-            // Prevent any accidental removal
-            if (!root.classList.contains('dark')) {
-                root.classList.add('dark');
-            }
+        const flipTheme = (): NodeJS.Timeout | undefined => {
+            const root = document.documentElement;
+            // Always use dark theme
+            const forcedTheme: Theme = 'dark';
+
+            // Ensure dark class is present
+            root.classList.add('dark');
@@
-        const timeoutId = flipTheme();
-        // Ensure dark class is always applied on mount and updates
-        const root = document.documentElement;
-        root.classList.add('dark');
-        
-        return () => clearTimeout(timeoutId);
+        const timeoutId = flipTheme();
+
+        return () => clearTimeout(timeoutId);

You could also optionally skip the updateUserTheme call when userTheme is already 'dark' to avoid unnecessary writes, but that’s an optimization rather than a correctness issue.

Also applies to: 68-81, 84-89, 94-100

---

125-128: changeTheme now ignores input and locks theme to dark

The changeTheme handler now discards the incoming value and always sets 'dark', which keeps the public context API stable while effectively disabling runtime theme switching. This is consistent with the rest of the forced-dark implementation. Longer term, you might either remove any UI that still calls changeTheme or rename/comment this handler to make its “no-op except enforcing dark” behavior explicit to future maintainers.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro